Internet Info 1994 March/Internet Info CD-ROM (Walnut Creek) (March 1994).iso/inet/ietf/noop/noop-minutes-92mar.txt

Text File | 1993-02-17 | 17.1 KB | 440 lines

CURRENT_MEETING_REPORT_


Reported by Sue Hares/Merit, David Bolen/ANS and Dave Miller/MITRE

Minutes of the Network OSI Operations Working Group (NOOP)

The Network OSI Operations Group met three times during the week of the
San Diego IETF. The first meeting took place on Monday morning.  Steve
Deering presented his ideas behind his paper ``City Codes is an
Alternative to Topological NSAP Allocation (RFC 1237).''  In addition,
Ross Callon presented the basics of RFC 1237.  Both presentations
prompted a great deal of discussion.  Sally Tarquinio took very detailed
notes of the discussion.  Due to the length of both the notes and the
discussion, the notes will not be available in the Proceedings.  Notes
may be retrieved via anonymous ftp from merit.edu in
/pub/iso/noop/notes/notes.03.16.92.am).

In addition to the City Code discussion, the following topics were
discussed:


   o Mobile Hosts
   o Comparison Geographical Area Code (GARP) with NAT and CNAT
   o GARP vs RFC 1237
   o Whether asymmetric pathways are acceptable.


The second NOOP session occurred on Wednesday morning at 9:00 a.m.  and
covered several different items.  Notes were taken by David Bolen.

Usage Questionnaire

Sue Hares made available copies of the OSI usage questionnaire and
requested that anyone involved with OSI work try to complete one.  This
was a copy of the same questionnaire that was previously distributed
electronically.

A question was raised as to why DECnet was considered different than
CLNP (p.  9) - the answer was that it wasn't really, but the goal was to
see if DECnet usage was pushing CLNP usage (here, DECnet really means
DECnet Phase V traffic).

NEARnet OSI Routing/Addressing Plan


   o Introduction
     John Curran from NEARnet (New England Academic & Research Network)
     made a presentation of NEARnet's OSI Plan.  NEARnet is comprised of
     120 members in six states, and coordinates with other New England
     service providers to provide service in that area.  Cisco routers
     are used throughout NEARnets network.

                                   1





o Address Assignment Plan
  When researching an address assignment plan, NEARnet found that
  area codes were a nice match for population density, and therefore
  for assignment beneath NEARnet's AAI.
  NEARnets final address format breakdown assumed the following
  limits:

   -  Total of 16 COs per area code.
   -  Total of 256 RDs per CO. This could be a real problem in a
      fairly short-term (~ two years).  It is hard to gauge demand
      though, and NEARnet isn't the only network assigning in the New
      England area.

  CO codes are assigned to aggregate at other boundaries as well:

          .00-.3F = Massachusetts    (.10 = 508 area code, .20 = 617, etc..)
          .40-.4F \
          .50-.5F  \  Assign to different states - allows room for
          .60-.6F  /  expansion according to area code.
          .70-.7F /
          .80-    still some slack available for future expansion


  The next step is then to assign RDs logically under this scheme.
  The multiple aggregation points within this scheme helps to limit
  the routing table size.
o Routing (ala RFC1237)
  The following points were raised with respect to routing issues
  under this sort of an address assignment scheme:

   -  Routes will often have to be manually injected.
   -  IGRP is not currently collapsing routes - hopefully newer
      protocols will begin to do this.
   -  NEARnet doesn't like the fact that they have to accept all
      routes as it allows NEARnet's routing tables to grow without
      bounds.
   -  NEARnet sees NSAP changes as a lot of work currently - thus, if
      a customer has already been assigned an RD, NEARnet lets the
      customer keep it.
   -  NEARnet will accept any other assignments, but isn't sure what
      will happen with other networks - will they be as accepting as
      NEARnet?

o Questions
  John brought up the general question as to what the general opinion
  of this plan was.  Could the approach be viewed as dangerous?  The
  following points were raised:

                                2





      -  Something has to be done, and at least this policy allows
         future aggregation - it's very hard to take back what we give
         out today.
      -  There could be a problem if all service providers don't become
         as accepting as NEARnet.  If routes begin to be refused, it
         might cause everyone to bail out to their own AAI which would
         create a flat address space once again.
      -  If we are allowing entropy at all (as this plan does), then
         there needs to be some sort of entropy reduction in the system.
         A possible recourse might be the need to start charging for the
         announcement of a special route to other networks.

     A general point was made that at the moment, the whole area of
     addresses and assignment represents more of a controlled economy
     than a true market economy.  Moving from one to the other is always
     tough.
     NEARnet's addressing and routing plan may be found (via anonymous
     ftp) in:
     nic.near.net:/docs/osi-routing-plan.txt or
     merit.edu:/pub/iso/noop/papers/nearnet.osi-routing-plan.txt
     John also gave credit to CICNet for their previously released OSI
     plan, and said that NEARnet's plan borrowed a lot from CICNet's.


OSI Pilot Projects

The discussion of OSI pilot projects centered around some documentation
that Sue supplied describing some of the work that RARE is doing in this
area.  RARE has a suite of tests that they are requesting users at their
sites to perform, sending them results back to a central site to be
summarized.  Sue was interested in whether or not their was enough
interest in trying the same sort of pilot plan here in the U.S., as well
as trying to get together another OSI demo for Interop East.

The general consensus of the Group was that, yes, it would be useful to
try the same sort of pilot project here, and that the RARE approach
seemed a reasonable way to proceed.  It would also be nice to see about
some coordination with RARE, although mostly for inter-domain and
application level than at the ES-IS and IS-IS level.  The
application-level portion of the RARE plan was a little weak, and may
need to be augmented for our tests.

A possible problem was brought up in that a number of sites have beta
implementations of OSI code, and may not be able to publish the results
of tests.  Sue suggested that at least saying ``I've tested'' is useful,
even if the exact results of the test cannot be released.

NIST was brought up as an organization that was already handling some
OSI testing in the same vein as what was being discussed.  NIST has
provided open labs and a test environment for multiple vendors to come
together in order to test interoperability.  There has been no automated

                                   3





or documented test procedures followed, however - just vendor engineers
running particular tests.  Richard Collela will be sending some further
information about this testing to the NOOP mailing list.

The fundamental difference between the testing that has been performed
at NIST, and the type of pilot projects being run by RARE is that the
latter case involves actual end users, while the former is run by the
vendors and their engineers.

John Curran suggested that the request for tests be sent out to the NOOP
list.  While many midlevels may not run the tests themselves, they may
have clients that can.  Sue Hares agreed to send the test plan, and a
request for volunteers to the NOOP mailing list.

Document Review:  (reported by Dave Miller)


   o TOOLS RFC
     Their was a brief discussion on the ``Tools'' Document and the need
     for tools to provide OSI ping, OSI traceroute, and OSI routing
     table dump utilities.  The discussion then focused on what routing
     table information should be available via SNMP. It was noted that
     the document should specify a minimal set of objects as MUST
     requirements for this specification.
     For CLNS MIB objects, no one took exception to the list in the
     draft document.  For IS-IS, the document currently states the
     object in very general terms.  Dino Farinacci was asked to write-up
     a minimal list of IS-IS objects and send them to the NOOP mailing
     list.  For IDRP, no one took exception to the list in the draft
     document.
     There was no review of objects for CMIP management at this time.
   o SURVEY FORM
     Sue Hares gave a status overview of the OSI in the Internet Survey.
     The plan to maintain the survey is to perform a monthly revision to
     incorporate any new information received.  Sue also encouraged
     others to respond to the survey since only about ten responses have
     been received to date.
     There were a few suggestions to modify the survey (it was noted
     that the changes should be highlighted when new surveys are sent
     out):

      -  DECnet traffic should refer to DECnet Phase V traffic.
      -  Text should refer to RFC 1006 as opposed to a TCP/IP stack.
      -  There should be a context section added to identify who's
         responding to the survey and what their role in OSI is.

     Cathy Wittbrodt suggested that the surveys be stored individually
     on-line so particular responses could be retrieved as desired.  Sue
     agreed to do this.

                                   4





     Dave Farber suggested sending the survey out to the IETF mailing
     list to reach a broader community.  Sue agreed to do this.
   o SECURITY RFC
     Walt Lazear gave an overview of the OSI Packet Filtering document.
     The document discusses the issues associated with filtering OSI by
     application type in the context of using packet filtering to
     restrict OSI connections (establishing firewalls).
     Walt noted that he has not received comments on the current
     document and solicited feedback.
     There was some discussion of what were the security requirements
     that were trying to be met.  MITRE was asked if they could put
     together a short paper on OSI security policy to set the context
     for this work and to stimulate further discussion.  Bill Barns
     volunteered himself and Walt to pursue this.
   o NIST IS-IS TEST LAB
     Rich Colella gave a quick overview of the IS-IS test lab
     established at NIST. Two Open Lab sessions have been conducted to
     date to perform vendor interoperability testing.
     A report of the router testing is being prepared.  Rich agreed to
     get a copy of the completed report sent to the NOOP list.


The third NOOP sessions took place during the 7:00 p.m.  session on
Wednesday, March 18th, and was devoted to discussion of the IDRP for IP
document.  A new working group will be formed to discuss the IDRP
issues.  Detailed notes are available via ftp, cd ietf, get
noop-minutes-92mar.txt).

NOTES>>>>>>>

IDRP for IP

IDRP can be found in merit.edu:/pub/iso/idrp.ps IDRP for IP will be
submitted as an Internet Draft by April 1st.


  1. BISPDU (IDRP packet) in IP packet with unique protocol ID.
     IDRP provides a reliable transport so TCP not needed.
  2. IP addresses encoded in NLRI and NET.
     Current ANSI ballot proposal will allow direct encoding.  This
     ballot proposal will be a correction on the current DIS ballot
     text.
  3. IDRP for IP only has:

       o No CLNP forwarding
       o No IDRP GMDO for CMIP: (MIB will be part of an Internet
         standard.  Internet is using SNMP over CLTS.)


                                   5





  4. Minimal Configuration Information needed for IDRP.

       o Intra-Domain ISs (routers)
       o Location and identity of BIS (Border routers) in Domain
       o IP addresses for Routing Domain (bag of networks)
       o Routing Domain Identifier (RDI)
         (New style AS)
         47:0005:81:aa:aa
         Where if AS number needs to be expanded, the aa:aa field can go
         to 4 bytes.
       o Rib Attribute Set = null
         Rib Attributes identify QOS. QOS will be examined in a separate
         document.
       o Routing Domain Confederations - RDCs
         Routing Domain Confederations this node is a part of.
       o SNPAs of this node

  5. IDRP compared to BGP-4.
     Additional Features

       o DIST_LIST_INCL, DIST_LIST_EXCL
         DIST_LIST_INCL indicates which routing domains a set of routing
         information may be passed to.  DIST_LIST_EXCL states this
         routing information may be passed to all RDs but the ones
         listed.
       o Local Preference (may be added to BGP-4)
       o MULT_EXIT_DISC (may be added to BGP-4)
       o RDC
       o RD Sets
       o IDRP has its own transport
       o Hierarchical Recording

  6. IDRP Deployment.

       o Minimum configuration:  1 BIS, 1 BIS can pass to intra-domain
         routing.
       o IP Prefix goes in 1 Routing domain, not multiple.
         Prefix is really 1 campus or RD, not the large ``bags'' of
         networks that make up AS now.


Attendees

Andy Adams               [e-mail]
Vikas Aggarwal           [e-mail]

                                   6





Robert Aiken             [e-mail]
Steve Alexander          [e-mail]
Nagaraj Arunkumar        [e-mail]
Zorica Avramovic         [e-mail]
William Barns            [e-mail]
Tony Bates               [e-mail]
William Biagi            [e-mail]
David Bolen              [e-mail]
Scott Brim               [e-mail]
J. Nevil Brownlee        [e-mail]
Eric Brunner             [e-mail]
Niels Brunsgaard         [e-mail]
Ross Callon              [e-mail]
John Chang               [e-mail]
A. Lyman Chapin          [e-mail]
Henry Clark              [e-mail]
Alan Clegg               [e-mail]
Richard Colella          [e-mail]
Rob Coltun               [e-mail]
Robert Cooney            [e-mail]
Curtis Cox               [e-mail]
Dave Cullerot            [e-mail]
John Curran              [e-mail]
Steve Deering            [e-mail]
Kathleen Dodd            [e-mail]
Tom Easterday            [e-mail]
Dino Farinacci           [e-mail]
Stefan Fassbender        [e-mail]
Peter Ford               [e-mail]
Karen Frisa              [e-mail]
Vince Fuller             [e-mail]
Eugene Geer              [e-mail]
Robert Hagens            [e-mail]
Susan Hares              [e-mail]
Jeff Hayward             [e-mail]
Juha Heinanen            [e-mail]
Randy Hoebelheinrich     [e-mail]
Kathleen Huber           [e-mail]
Bob Jeckell              [e-mail]
Barbara Jennings         [e-mail]
Dan Jordt                [e-mail]
Dave Katz                [e-mail]
H. A. Kippenhan          [e-mail]
Yoav Kluger              [e-mail]
Deidre Kostick           [e-mail]
Eva Kuiper               [e-mail]
John Larson              [e-mail]
Walter Lazear            [e-mail]
Eliot Lear               [e-mail]
Kurt Lidl                [e-mail]
Susan Lin                [e-mail]
Tony Li                  [e-mail]
Triet Lu                 [e-mail]
Gary Malkin              [e-mail]

                                   7





Bill Manning             [e-mail]
Glenn McGregor           [e-mail]
Milo Medin               [e-mail]
David Miller             [e-mail]
Henry Miller             [e-mail]
Greg Minshall            [e-mail]
Dennis Morris            [e-mail]
Donald Morris            [e-mail]
Brad Passwaters          [e-mail]
David Piscitello         [e-mail]
Jon Postel               [e-mail]
Rex Pugh                 [e-mail]
Yakov Rekhter            [e-mail]
Ron Roberts              [e-mail]
Jonathan Rodin           [e-mail]
Benny Rodrig             [e-mail]
Manoel Rodrigues         [e-mail]
Sharad Sanghi            [e-mail]
Erik Sherk               [e-mail]
William Simpson          [e-mail]
Keith Sklower            [e-mail]
Mark Sleeper             [e-mail]
Frank Solensky           [e-mail]
Walter Stickle           [e-mail]
William Streilein        [e-mail]
Sally Tarquinio          [e-mail]
Richard Thomsen          [e-mail]
Claudio Topolcic         [e-mail]
Paul Traina              [e-mail]
Kannan Varadhan          [e-mail]
Huyen Vu                 [e-mail]
Carol Ward               [e-mail]
Bert Wijnen              [e-mail]
Steve Willens            [e-mail]
Scott Williamson         [e-mail]
Walter Wimer             [e-mail]
Linda Winkler            [e-mail]
Cathy Wittbrodt          [e-mail]
Peter Yee                [e-mail]



                                   8